…ub-hub reads parent)

A hub initializes and syncs its own EntityStore under its own credential (ImpersonateAsHub
=> AccessContext.ObjectId = the hub's mesh address) and a sub-hub subscribes to its parent/
owner the same way. No AccessAssignment ever exists for a hub address, so the owner's RLS
denied that Read => the sub-hub never got its parent's snapshot, its layout area never
rendered, and FutuRe LineOfBusiness Search timed out (50s). Access was not propagating.

Mark hub credentials explicitly (AccessContext.IsHub, set by both ImpersonateAsHub paths)
and grant a hub credential Read on its OWN path + ANCESTOR scopes only (the sync direction)
- never siblings, descendants, the mesh root, or a non-hub identity. Short-circuits before
the cold permission-query path, so hub self-sync no longer rides it either.

Repro: HubCredentialReadAccessTest.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

On ConnectStatus.Connected the widget showed "✓ Connected" but stayed up until the
user clicked ✕. Now it auto-dismisses ~1.2s after success via a reactive
Observable.Timer (no Task.Delay), stored in _connectSub so a dispose / new connect
cancels the pending close. New CloseConnectWidget clears the UI state without
cancelling the (already-completed) session.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

On ConnectStatus.Connected the widget showed "✓ Connected" but stayed up until the
user clicked ✕. Now it auto-dismisses ~1.2s after success via a reactive
Observable.Timer (no Task.Delay), stored in _connectSub so a dispose / new connect
cancels the pending close. New CloseConnectWidget clears the UI state without
cancelling the (already-completed) session.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… side-panel header

.thread-chat-widget floats up from the input (bottom: calc(100%+6px)); a fixed
280px (or the login dialog's 560px) overran the "New Thread" side-panel header on
a short panel — the agent/model picker AND the login dialog were clipped at the
top. Cap at min(440px, calc(100vh - 180px)) so it always fits between the header
and the input; the inner list scrolls past that. Drops the login widget's bespoke
inline max-height in favour of the shared responsive cap.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…d it back

"Not logged in after reload": the token IS stored in the ModelProvider node, but
the harness's oauthToken comes from the node-backed resolver whose cache is cold
after a reload / pod restart, and `claude setup-token` only PRINTS the token (it
never writes .credentials.json) — so nothing authenticated the CLI.

Now ClaudeConnectStrategy.PersistCredentials writes the captured token to
{configDir}/.credentials.json on the shared config-dir volume (inside the Process
IoPool worker; sync I/O), and ClaudeCodeChatClient falls back to reading it
(effectiveToken = oauthToken ?? ReadCredentialsToken) when the resolver returns
null — so CLAUDE_CODE_OAUTH_TOKEN is still set and the session authenticates.
ConnectStrategyTest now asserts the file is written holding the captured token.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…CLI exit 1)

A `claude setup-token` token is consumed via the CLAUDE_CODE_OAUTH_TOKEN env var,
NOT a .credentials.json file (that file is the interactive `claude login` OAuth-
bundle schema). Writing the token there made the CLI parse a malformed creds file
and exit 1 (the blackout + ProcessException). Revert PersistCredentials + its test
assertion. The token still lives in the persistent ModelProvider node and is
re-applied to CLAUDE_CODE_OAUTH_TOKEN by the harness (effectiveToken); the harness
also reads back the CLI's OWN .credentials.json when present (harmless, kept).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…s (match PG)

The in-memory storage adapter keeps satellites in one store, so a content query
(e.g. scope:descendants) returned satellite-path nodes that PG never would (PG
stores _Access/_Thread/... in separate per-prefix tables). This surfaced as the
auto-created {partition}/_Access/{creator}_Access grant polluting Query.Test results.
RunQueryNodes now drops satellite-path rows for non-satellite-targeted queries;
explicit satellite queries (a _-segment path, satellite nodeType, source:activity/
accessed) are unaffected. Mirrors the existing MergeAutocompleteSnapshots exclusion.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ty (fixes blackout)

The per-thread submission watcher's own-writes (ReconcileUserMessageIds + the
claim Update) drive the data-source SynchronizationStream.Update, which posts a
User-attributed UpdateStreamRequest from the sync/<id> hub. The watcher fires on
a scheduler that does NOT carry the originating user's AsyncLocal AccessContext
(null on the Orleans grain / no circuit), so the post went out with NO
AccessContext -> the never-null PostPipeline guard failed it -> a DeliveryFailure
storm the submit never recovered from = "thread disappears on submit". Fix: wrap
both own-writes in AccessContextScope.FromNode(threadNode) so they FORCIBLY run
under the thread OWNER's identity (the access check already gated the submit; the
round inherits that trust). No System impersonation, no null-tolerant fallback.
Test: ExecuteThreadMessageTest.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…s /code skill

The chat slash-skill autocomplete only offered the 3 built-in skills (agent/
model/harness) because it didn't collect space/user skills. BuildSkillQuery now
lists namespace:{user}/Skill|{space}/Skill|Skill nodeType:Skill — the SAME
per-partition registry pattern as agents/models, reserved-partition filtered —
and SkillAutocompleteProvider uses it, so a user's/space's Skill nodes (e.g.
AgenticPension/Skill/*) appear in the autocomplete via inheritance. Adds a /code
built-in skill (Data/Skill/code.md). Tests: AgentPickerQueriesTest.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

abac5de auto-provisions a Space root at each partition path with a CURRENT
LastModified. Being a real mesh_nodes row (not a satellite), it leaked into content
queries on PG and in-memory alike — dominating recency sorts (is:main
scope:descendants sort:LastModified-desc) and showing up under exact partition-path
reads. Partition roots are structural containers, not content: RunQueryNodes now drops
them unless the query explicitly targets nodeType:Space. Fixes FanOut + EmptyQuery and
the real 'partition roots flood recent-items' regression.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The RC line is done; bump the central PlatformVersion default to the clean
release. The version machinery already supports a non-prerelease core (continuous
builds switch the suffix to -ci.N; AssemblyVersion stays 3.0.0.<build>).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…envs

Every merge to main that passes 'MeshWeaver Build and Test' (gated via workflow_run)
builds the memex-portal-ai + memex-migration images to the shared ACR (tagged by
commit SHA + moving 'main'), then rolls them out to memex, atioz, and memex-cloud
via the documented kubectl set-image + rollout flow. The RELEASED channel (clean
NuGet + GHCR images on a v*.*.* tag) is unchanged.

Requires Azure CI credentials (AzureN OIDC: AZURE_CLIENT_ID/TENANT_ID/SUBSCRIPTION_ID
with AcrPush + az aks command invoke rights) before it can run.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…push)

Adds GitWorkingTreeService: clone a GitHub repo onto the workspace volume, read/
write files, commit, and push — the working-tree counterpart to content sync,
shared by the in-portal editor AND the co-hosted AI CLIs. Reactive end-to-end;
git runs as a blocking Process leaf through IIoPool, the user's token is injected
via an env-based credential helper (never in argv), and paths are per-user isolated.

Infra: a memex-workspace RWX PVC mounted at /workspace (memex + memex-cloud only,
NOT atioz), and git added to the portal-ai base image (the AI CLIs need it too).

Hermetic tests cover the full clone->edit->commit->push round trip against a local
bare repo, idempotent re-clone, the no-credential error, and path-escape rejection.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…r (kills residual AccessContext storm)

InitializeThreadLifecycle's self-healing recovery observation drove its writes
(Executing->Idle reset, HonorPendingCancelOnWake, ResumeInterruptedRound)
WITHOUT the AccessContextScope.FromNode owner scope that ExecRoundWatcher already
applies. On a context-less re-establish continuation those writes posted an
UpdateStreamRequest from the sync hub with null AccessContext -> the never-null
PostPipeline guard failed it -> a DeliveryFailure storm that faulted the
observation -> it re-established in a tight loop ("[ThreadExec] Init observation
faulted for Thread - re-establishing", ~44/70s on atioz). Wrap the whole recovery
handler in AccessContextScope.FromNode(node) so every recovery write forcibly
carries the thread owner's identity. Same root-cause class as the submission-
watcher fix (3f28da5) -- forcibly have an AccessContext = thread owner.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…t exact path

The partition-root exclusion broke UserPublicReadTest.DynamicallyCreated_SpaceNode:
an exact 'path:Globex' read of an explicitly-created Space must return it. Scope the
exclusion to non-Exact (Children/Descendants/Ancestors) queries — where structural
roots pollute listings/recency (FanOut) — and leave EXACT path reads alone. Update
QueryAsync_EmptyQuery to assert on an intermediate namespace-prefix ({p}/sub), which
genuinely has no node, since the first-segment partition root {p} is now auto-provisioned.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The access-denied warning didn't name what triggered it, so a denial on a
rogue/reserved path (e.g. 'login') was an unattributable warning. Log the
delivery message type + sender + hub so the caller can be pinned.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…r stale bare MainNode

ROOT (systemic): AccessService.Context is a per-hub AsyncLocal -- it flows through
await/ConfigureAwait(false) within one hub but is null on any other hub's scheduler
or a continuation that crossed a hub boundary. So every deferred write that reaches
SynchronizationStream.Update (layout-area render emissions, watchers, the agent
streaming loop, thread paths) posted UpdateStreamRequest with a null AccessContext,
which the never-null PostPipeline guard fails closed -> the "hub=sync/...
UpdateStreamRequest ... no AccessContext" DeliveryFailure storm (layout areas
$Menu/$Dialog/Settings, threads, AI-settings back-forth).

FIX 1 (central, the chokepoint): SynchronizationStream captures the subscribing
user's AccessContext ONCE at construction (the circuit / SubscribeRequest handler
thread, where AccessService.Context is the real user) with a first-subscribe
fallback, and Update restores it when the live context is null:
  capturedContext = CaptureCallerAccessContext(hub) ?? _creationContext;
A present live context always wins; CaptureRealUserContext refuses null/IsHub/
hub-shaped(sync,mesh,node,activity,portal)/system-security, so a hub identity can
never leak into CreatedBy and infra-created streams fall back to existing behaviour.
Carries identity through ALL deferred continuations at one seam instead of
site-by-site FromNode patches.

FIX 2: a node first built BARE (new MeshNode("Datenextraktion")) keeps its stale
bare MainNode after a later `with { Namespace }` (MainNode is stored, not computed),
and that bare id flows MainNode -> NavigationContext -> StartThread namespace -> a
thread created under the non-existent "Datenextraktion" partition -> Postgres 42P01.
Re-stamp MainNode = Path at the create boundary, with a precise trigger (MainNode ==
bare Id on a namespaced non-satellite node) that spares legitimate parent-pointer
MainNodes (e.g. GitHubSyncConfig.MainNode = spacePath).

Also: update SkillNodeTypeTest for the /code built-in skill (37e4541 shipped the
skill but never updated this assertion -> HEAD was red).

Tests: StreamUpdateIdentityTest (continuation Update restores captured context;
hub-address stream captures null), PartitionRootBootstrapTest (+MainNode repair),
Data.Test 239/239, AI.Test 574 + SkillNodeTypeTest 7/7.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…r per-harness status bar)

Skills become harness-scoped DIMENSIONS: a skill is a value + a picker + a status
chip — one concept end to end. New SkillDefinition.Harness (null = MeshWeaver /
everywhere) lets each harness own its selectors through the existing skill/command
layer: Claude Code will ship /model + /effort (Harness="ClaudeCode"), Copilot its
own, MeshWeaver keeps /agent + /model. The status row then renders exactly the
ACTIVE harness's skills, each chip showing the current composer value and clickable
into its Pick combobox. This commit is the data-layer foundation (the field +
front-matter parse); harness-scoped discovery, the /effort skill + effort nodes,
and the skill-driven status row follow.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Adds WorkingTreeTab, a Space settings tab that checks out the Space's connected
GitHub repo as a working tree, lists its files, opens one in a Monaco editor, and
commits + pushes the edit as the user. Same visibility gate + reactive data-binding
pattern as the GitHub Sync tab; Monaco wiring mirrors CodeLayoutAreas.Edit. Wired
into MemexConfiguration next to the GitHub Sync tab.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…l AKS publish

The Release publish runs BakeMeshLocalFeed, which packs MeshWeaver.BusinessRules.
Because BusinessRules is decoupled from the portal project graph (#r nuget only),
the publish's implicit restore skips it, so a stale local obj lacking the
net10.0/linux-x64 target fails the publish with NETSDK1047. Document the one-line
restore fix; CI is immune (clean checkout). Hit while deploying the working-tree feature.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Documents the correct procedure for creating a Space so everything works: create
(not update, which skips partition provisioning + the creator-Admin grant), author
a real summary body (an empty Space renders a placeholder whose catalog embed shows
nothing), set a logo + icon, and optionally link a GitHub repo via _GitSync.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…caller context

SynchronizationStream.Update posted UpdateStreamRequest with a NULL AccessContext when
both the live AsyncLocal (lost on the Rx hop) and the captured creation context were null
— the cold-start case: the first cross-hub write into a freshly-activated owner. The
never-null PostPipeline guard failed it closed, so the patch never committed. This was the
Orleans cold-start submit deadlock (ColdStart_AgentSeesAllPreviousMessages, 2-core): the
user's pending message never landed on the thread node, the submission watcher saw
pending=0 forever, no round dispatched, Messages.Count stuck < 6 → 30s timeout.

The data-source sync write is INFRASTRUCTURE — the user's access was already enforced
upstream at the PatchDataRequest boundary — so it posts as System (the sanctioned infra
fallback per AccessContextPropagation.md) instead of a null context. Only the
currently-fail-closed null path changes; warm streams carry the creating user via
_creationContext and never reach the fallback. Verified: cold-start test 53s timeout -> passes 11s.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…when no caller context"

This reverts commit ec3cd7c.

…ave Settings (models+keys only)

Agents and skills are user/space CONTENT, not admin config:

- AgentChatClient base prompt: when the user repeats a multi-step task (this thread
  or across threads), the agent PROACTIVELY offers to save it as a /<name> Skill,
  and knows that "create a skill" means create a nodeType:Skill node (Instructions
  and/or Action) under {user}/Skill (private) or {space}/Skill (shared). Lives in
  the shared base prompt so every conversational agent offers it; one-shot/utility
  agents never see a repeating user so it never fires.
- ChatCommands.md: document the proactive behavior + user-vs-space creation.
- Settings is admin-only territory (models + keys): remove the Agents settings tab
  and retire AgentsSettingsTab.cs. Agents/skills surface on the user overview's
  namespace listing (UserActivityLayoutAreas children: namespace:{user}) and are
  created from chat -- no settings tab, no parallel UI.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…rry-forward CircuitContext

Documents prominently the standing rule: in a node/thread/activity context the NODE OWNER
(resolved from the node) is the access context, injected EVERYWHERE and CARRIED FORWARD across
Rx hops via CircuitContext (Context alone is wiped on the hop). Genuine infra (doc sync, cache
hydration) runs as System; an EMPTY context is rejected instantly, never faked into hub-self.

New doc Data/Architecture/OwnerInjection.md (cross-linked from AccessContextPropagation.md) with
the cold-start submit deadlock as the worked example (owner-side data-source sync write posted a
NULL UpdateStreamRequest -> fail-closed -> pending never landed -> 30s timeout).

Code: ThreadExecution.SetThreadHubIdentity now stamps the thread owner as BOTH Context AND
CircuitContext (the carry-forward slot). This is the thread-hub step of owner injection; the
remaining cross-cutting piece is injecting the owner at the per-node data-source sync stream
(a separate sync sub-hub does not inherit the thread hub's CircuitContext) — tracked in the doc.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…e mesh (never materialised to disk)

Comment-only fix on SkillDefinition (XML doc) + the mirrored ChatCommands.md inline
comment: AutoMount means an instruction skill is ADVERTISED up-front to the CLI
harnesses + the MeshWeaver agent so it's discoverable without being asked -- read
from the mesh on demand, NEVER materialised to a shared skills directory on disk.
Corrects the stale "mounted/materialised to disk" wording to match the actual
behaviour. No logic change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…r resolver, not async hub identity

Sharpen OwnerInjection.md with the proven root cause. SYNCUPD probe on the data-source sync
stream (ds/…/history-cold-start, whose Host IS the thread hub) shows two writes: the first
(cold-start submit pending) has hostReal=null and posts a null AccessContext (fail-closed); the
second, ~200ms later, has hostReal=TestUser. SetThreadHubIdentity establishes the owner
ASYNCHRONOUSLY (GetMeshNode round-trip) and the first write loses that race.

Correction to the prior note: the Host is NOT wrong/empty — it is the right hub; only the async
timing loses. The fix is a SYNCHRONOUS owner resolver: the data-source stream resolves the owner
from the node already in its Current (CreatedBy) at write time, wired by the MeshNode-aware
data-source layer (generic SynchronizationStream<EntityStore> can't read CreatedBy itself). This
removes the race; no System fallback (would violate StreamUpdate_WithoutAsyncLocalIdentity_FailsClosed).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Cross-link the Owner Injection rule (node owner = standing access context, injected everywhere,
carried forward via CircuitContext; doc-sync/cache = System; empty context rejected) from every
relevant doc: Architecture index (Security row) + Glossary term; ThreadOperations (new 'thread
identity = owner' section); CqrsAndContentAccess (never-null/GetStream); ActivityOperations +
ActivityControlPlane (activity owner); RequestViaStreamUpdate (identity across the cross-hub hop —
the cold-start race lives exactly here). DocumentationLinkIntegrityTest green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>